一套 Apps Script 打卡系統：從出勤紀錄、異常檢查到統計報表
SOLUTION / APPS SCRIPT SYSTEM
Apps Script 打卡系統：從出勤紀錄、異常檢查到統計報表
打卡聽起來很簡單：記錄誰在什麼時間簽到、什麼時間簽退。但實際工作中，麻煩的往往不是記錄當下，而是事後整理。
有人忘記簽退，有人補打卡，有人遲到但需要備註原因，有人一天有多個時段，有人跨場地支援。月底要統計時，管理者才發現資料需要人工判斷、人工補洞、人工對帳，耗時費力不說，還不一定完全正確。
這系統想處理的問題是：打卡資料能不能在產生的當下就整理好，讓異常、統計與報表不要等到月底才處理？
這套系統想解決什麼問題
一般打卡紀錄常見的問題，是紀錄有了，但管理邏輯沒有跟上：
- 簽到、簽退只是流水帳，月底仍要人工整理時數。
- 忘記簽退、重複打卡、跨日紀錄等異常不容易即時發現。
- 補打卡與請假說明沒有固定格式，日後難以追溯。
- 班表、出勤與實際服務時數分開保存，需要人工比對。
- 統計報表每月重新整理，口徑容易前後不一致。
這些問題不是打卡按鈕不夠好，而是打卡資料沒有被設計成可檢查、可統計、可回報的流程。
系統骨架：每一次打卡都留下可判讀的紀錄
這套系統可以用 Google Sheets 作為資料中心，Apps Script 建立 Web App 介面。使用者透過手機或電腦打卡，資料寫入試算表；系統同時做初步檢查與狀態判定。
- 打卡入口：簽到、簽退、補打卡、請假或備註。
- 原始紀錄：保留每一次送出時間、使用者、狀態與備註。
- 異常檢查：偵測缺簽退、重複打卡、超過時段、時數異常。
- 月度統計：依人員、日期、活動、場域彙整出勤與服務時數。
- 報表輸出：產出管理表、個人紀錄或月報摘要。
重點是保留原始紀錄，同時產出可管理的摘要。原始資料不被覆蓋，統計資料則自動生成。
畫面與流程設計
打卡首頁：只留下最必要的選項
打卡介面簡單易用。使用者打開頁面後，只需要看到自己的姓名、目前時間，以及幾個清楚按鈕：簽到、簽退、補打卡、請假或備註。
真正複雜的判斷放在系統後面，讓系統自動根據設定好的規則自動處理所有資料。
異常清單：管理者先看需要處理的紀錄
管理者需要的不是一整張流水帳，而是異常清單。系統可以自動標示：今天誰只簽到沒簽退、誰重複打卡、誰的服務時數超出合理範圍、誰需要補資料。
這樣管理者不用逐列檢查，而是先處理真正需要判斷的項目。
補打卡流程：留下原因，而不是直接改資料
補打卡最容易造成資料混亂。好的做法不是直接修改原始時間，而是新增一筆補打卡申請或管理備註，保留原本缺漏，也保留後來修正的理由。
這樣日後若要查核，就能知道原始紀錄是什麼、誰補了資料、為什麼補。
月報統計：讓出勤資料自動變成報表
打卡資料若事先設計好欄位，月底統計可以自動產生：每人出勤天數、服務時數、遲到次數、缺漏紀錄、補打卡次數，甚至不同活動或場域的服務量。
這些數字可以直接作為內部管理、計畫報告或補助核銷的基礎。
使用系統的優點
首先，它省下的是月底整理時間：
- 出勤時數：由人工加總，改為系統自動彙整。
- 異常紀錄：由月底才發現，改為當天或當週即可處理。
- 補打卡：由口頭說明，改為留下可追溯紀錄。
- 報表輸出：由每月重做，改為固定格式自動產出。
更重要的是，它讓出勤資料變成可被信任的管理資料。管理者看到的不只是誰有打卡，而是哪些紀錄完整、哪些需要補正、整體人力如何被使用。
為什麼適合用 Apps Script
打卡系統不一定一開始就需要昂貴設備或大型 HR 系統。若團隊規模不大，且工作流程本來就依賴 Google Sheets，Apps Script 可以快速建立一套輕量、可調整、可查核的打卡流程。
它尤其適合志工團隊、課程助教、社群活動、專案人員、服務據點或臨時工作人員。這些情境的共同點是：需要紀錄時間，但更需要把時間變成可管理的資料。
如果你的打卡資料每月都要重新整理
可以先問三個問題：誰需要打卡、什麼情況算異常、月底要產出哪些統計。只要這三件事清楚，打卡系統就不只是簽到工具，而是一套出勤資料管理流程。